Field of the Invention
The field of the invention is data processing, or, more specifically, methods, systems, and products for correlating business workflows with transaction tracking.
Description Of Related Art
Service-Oriented Architecture (‘SOA’) is a business integration application architecture for running business processes that invoke information technology (‘IT’) resources in a distributed processing environment. Such business processes are typically written in a business processing language such as the Business Process Execution Language (‘BPEL’). Such business processing languages are typically used to abstract the execution of the business process from actual IT resources called by the process. IT resources are downstream computer resources available to a business process. Examples of such IT resources are web services, Enterprise Java Beans (‘EJBs’) running on an EJB server, databases, Java services, and other computer resources that will occur to those of skill in the art.
In typical SOA implementations, all information technology (‘IT’) functions, or services, are defined using a business process description language. SOAs also have invocable interfaces that are called to perform business processes. SOA enables building a web-services-based layer of abstraction over legacy systems and outside services and subsequently leveraging the legacy systems and outside services to assemble business processes. The legacy systems and outside services leveraged by SOA applications often heterogeneous applications and technologies. A typical SOA application may contain a business process and downstream IT transactions invoked by the business process.
Transaction tracking tools are widely used to track transactions typically occurring in a distributed computing environment. Transaction tracking is carried out by passing a correlator at an instrumentation point and gathering data about the transaction with the passing of the correlator. An instrumentation point is a call to a transaction tracking tool to begin gathering information about the transaction. Management software is typically then used to display information gathered at the instrumentation points about the transactions.
One specific transaction monitoring application programming interface (‘API’) is the Application Response Measurement (‘ARM’) API. ARM is an industry standard for tracking the performance of programs. ARM commands include commands in Java or C to initiate an application, to create a transaction ID, to start and stop monitoring transactions, and to end all monitoring. ARM provides for correlating the information of transactions by passing a data structure called a correlator from a parent transaction to a child transaction. ARM uses the data to create a data structure that represents the relationships of the transactions being monitored. The data produced by the ARM API can be collected by management software for use in displaying information about the transactions monitored.
Traditional tracking tools, such as for example ARM, are not, however, fully utilized in correlating the business processes with the IT transactions that carry out the business process because there is little or no correlation between the downstream IT resources that carry out business processes and the business processes themselves. IT transactions are instead tracked separately as transactions unrelated to the business process they support. This provides no linking in the transaction tracking of the IT resources and the transaction tracking of the business process they support.
Two methods for attempting to extend the IT tracking to business processes currently exist. One method of extending IT tracking to business processes includes inserting artificial business process artifacts into business processes. These artificial artifacts carry on the tasks of the instrumentation and correlation of transactions typically carried out by ARM or other transaction tracking tools. In order to gather performance data with this method, business process modelers insert business method specific monitoring calls as business artifacts immediately before and after each actual business activity. This insertion of artificial artifacts in the business processes works only for uninterruptible workflows with synchronized request/response activities executed locally on a single machine. In other words, this conventional method cannot handle long-running processes such as asynchronous activities in distributed environment. The method fails because implementation specific object instances are not accessible at the business process level. Therefore, data structures to be used to convey correlations between transactions cannot be carried to different execution threads or to remote machines. That is, the underlying IT transactions carrying out the business methods cannot be tracked using this method. Further, this method requires business process modelers to add artificial business process artifacts around every business process in every business process script for which transaction tracking is desired. In many cases, this insertion of artificial processes is cumbersome.
A second method for attempting to extend transaction tracking to business processes provides for automating audit event callbacks that are accessible through an engine that implements business processes (‘business process engine’). Business process activities are then correlated with the event data produced by the callbacks. This method, however, does not enable end-to-end business transaction correlation because audit event callbacks are designed to provide aggregate information about activities of business processes, not IT resources. In order to activate the audit events, a business process modeler must modify every existing business process workflow to add a flag in each activity of every business process. In many cases, adding the flag at each activity is cumbersome.